Explicit Congestion Notification (ECN) has been proposed for use within Internet Protocol (IP) networks, and involves ECN capable routers marking packets as having experienced congestion by the use of specific ECN fields within the packet header, rather than dropping the packet and leaving the receiver to infer congestion, as had previously been the case (as packet loss could also be caused by transmission errors, loss of a packet is no definitive indicator of network congestion). Within IP, a two-bit field within the IP header has been proposed to enable the marking of packets, comprising a first ‘ECN-Capable Transport’ (ECT) bit (which was generally intended to be used to indicate whether the end-points of the transport protocol were ECN capable) and a second ‘Congestion Experienced’ (CE) bit (which was generally intended to be marked by routers in the event of congestion to indicate that the packets has experiences congestion). The use of two bits within the IP header provides four code-points, however, ([ECT,CE]: [0,0], [0,1], [1,0], and [1,1]) and RFC 3168 (see FIG. 1 thereof) defines two of these as being indicative of ECN capability ([0,1] and [1,0], referred to as ECT(1) and ECT(0) respectively), leaving the code-point [0,0] to indicate a lack of ECN capability, and the code-point [1,1] to indicate a ‘Congestion Experienced’ state. Senders are free to use either the ECT(0) or the ECT(1) code-point to indicate ECT, on a packet-by-packet basis. The use of both the two code-points for ECT, ECT(0) and ECT(1), is motivated primarily by the desire to allow mechanisms for the data sender to verify that network elements are not erasing the CE codepoint, and that data receivers are properly reporting to the sender the receipt of packets with the CE codepoint set, as required by the transport protocol.
Regarding uses of the ECN marks, Henderson et al. in Congestion Pricing: Paying Your Way in Communication Networks, IEEE Internet Computing, September/October 2001 pp. 77-81 proposed their use for both congestion signalling purposes and for congestion pricing. In particular, Henderson et al suggest that since the mark indicates network congestion, the network can aggregate marks to represent a “shadow price” for a flow, reflecting the cost of the congestion which it causes. Such an approach indicates a “per flow” charging policy, however, which may not be practicable, and especially between different network domains which a flow may encounter between the sender and receiver, due to the potentially high number of individual flows which might pass between two network domains. Additionally, there is an added problem using ECN marks to generate the shadow price that it is not until the packets of a flow have arrived at the receiver that the number of packets in the flow with the CE code-point set can be properly measured, as at any point on the route before this further packets may have the CE code-point set at any router later in the route. There is therefore a further problem of generating the level of shadow charges for use on an inter-domain basis between network domains without having knowledge of the total shadow charge which will ultimately arise.
Referring now to prior art patent documents, European patent application EP 1,317,151 relates to a method for congestion control signalling for use in a wireless network, and includes a brief review of the uses of ECN marks for congestion control signalling.
U.S. Pat. No. 5,751,969 relates to apparatus and methods for predicting and managing congestion in networks.
UK patent application GB 2,281,005 to a manner of self-regulating traffic to avoid congestion in an Asynchronous Transfer Mode (ATM) network.
United States patent application US 2003/0097461 relates to systems and methods for controlling network demand via congestion pricing, and includes a discussion of ECN-based schemes.